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Remarks 

Claims 1 to 37 are pending in this application. Claims 1, 10, 18, 19, 20, 
and 33 are independent. No claims are changed in the present Response. 

Claims 1-17 and 19 stand rejected by the Examiner under 35 U.S.C. § 
102(e) in view of U.S. Patent Application No. 2003/0126195, filed by Daniel A. 
Reynalds era/, on April 10, 2001 (hereinafter, "Reynolds"). Claim 18 stands rejected 
by the Examiner under 35 U.S.C. § 103(a) as being unpatentable over Reynolds in 
view of U.S. Patent No. 6,549,943, issued to Maximilian Spring et al. on April 15, 
2003 (hereinafter, "Spring"). Claims 20-37 stand rejected by the Examiner under 35 
U.S.C. § 103(a) as being unpatentable over Reynolds in view of U.S. Patent 
Application No. 2001/0055017, filed by Bas Ording et al. on January 5, 2001 
(hereinafter, "Ording"). 

Applicant's arguments in response to the shortcomings of the teachings of 
Reynolds and Ording have been articulated in the previous office actions, all of 
which are incorporated herein by reference. 

Claim Rejections - 35 U.S.C. § 102(e) 

Claims 1-17 and 19 stand rejected by the Examiner under 35 U.S.C. § 
102(e) as anticipated by Reynolds. Applicants respectfully traverse this rejection. 

Independent claims 1 and 10 recite "monitoring program code, 
asynchronous with respect to said control program code, for generating at least one 
event indication in response to a change of at least one predetermined attribute 
of said embedded device and forwarding said at least one event indication to said 
control program code". 

There are no teachings in Reynolds of a monitoring program doing anything 
in response to a change in an attribute of the embedded device. See Reynolds at 
paragraphs [0504] through [0506]. 



U.S. Pat. Ser. No. 10/016,597 
July 6, 2006 
Page 11 of 15 



[0504] Master SMS 184 periodically polls installation 
directory 1222 for new sub-directories including new 

releases, for example, release 1.1 1218 in sub-directory 
1220. When the master SMS detects a new release, it opens 
(and decompresses, if necessary) the packaging list in the 
new sub-directory and verifies that each software component 
listed in the packaging list is also stored in the new sub- 
directory. The master SMS then performs a checksum on 
each software component and compares the generated 
checksum to the checksum appended to the software com- 
ponent. 

[0505] Once all software components are verified, the 
master SMS opens (and decompresses, if necessary) an 
upgrade instruction file also included as one of the software 
components loaded into sub-directory 1220 from the Instal- 
lation Kit. The upgrade instruction file indicates the scope of 
the upgrade (i.e., upgrade mode). For instance, the upgrade 
instruction file may indicate that the upgrade may be hot or 
cold or must only be cold. The upgrade instruction file may 
also indicate that the upgrade may be done only across the 
entire chassis — that is, all applications to be upgraded must 
be upgraded simultaneously across the entire chassis — or 
that the upgrade may be done on a board-by-board basis or 
a path-by-path basis or some other partial chassis upgrade. 
A board-by-board upgrade may allow a network device 
administrator to chose certain boards on which to upgrade 
applications and allow older versions of the same applica- 
tions to continue running on other boards. Similarly, path- 
by-path or other service related upgrades may allow the 
network administrator to chose to upgrade only the appli- 
cations controlling particular services for particular custom- 
ers, for example, a single path, while allowing older versions 
of the applications to continue to control the other services. 
Various upgrade modes are possible. 

[0506] The upgrade instructions file may also include 
more detailed instructions such as the order in which each 
software component should be upgraded. That is, if several 
applications are to be upgraded, certain ones may need to be 
upgraded before certain other ones. Similarly, certain soft- 
ware components may need to be upgraded simultaneously. 
Moreover, certain boards may need to be upgraded prior to 
other boards. For example, control processor card 12 may 
need to be upgraded prior to upgrading any line cards. 
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Nothing is done to monitor the board's (compare to Applicants "embedded device") 
attributes; all actions are taken by the Master SMS. Paragraph [0504] does do 
polling, but it polls the installation directory, not the embedded device. 

The argument in both the first office action and the current office action 
recite the claims language for this term verbatim and then provides the citation to the 
above paragraphs. Elements of a claim can not be ignored. If the elements do not 
exist in Reynolds, then a 35 U.S.C. § 102(e) rejection can not be sustained. The 
second office action states: 

b. In response to Applicant's arguments in the second paragraph of p. II, Reynolds et al. 
discloses that, a board-by-board upgrade may allow a network device administrator to [choose] 
certain boards on which to upgrade applications and allow older versions of the same 
applications to continue running on other boards (paragraph [0505]). 

However, this too, fails to show where the "monitoring program... generating at least 
one event indication in response to a change... of an attribute of the embedded 
device" claim term is found. 

This element is simply missing from the teachings of Reynolds, and claims 
1 and 10 are not anticipated. The rejection under 35 U.S.C. § 102(e) must be 
withdrawn. 

Claims 2-9 and 11-17 depend upon depend upon claim 1 or 10 and are 
therefore distinct from Reynolds for the above reasons. 



Independent claim 19 also includes the term "...means for monitoring an 
embedded device..." As discussed above, this is not taught by Reynolds and the 
rejections under 35 U.S.C. § 102(e) must be withdrawn. 
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Claim Rejections - 35 U.S.C. § 103(a) - Reynolds/Spring 

Claim 18 stands rejected by the Examiner under 35 U.S.C. § 103(a) as 
unpatentable over Reynolds in view of Spring. Applicants respectfully traverse this 
rejection. 

Reynolds is drawn to a common command interface to provide an 
interface abstraction for network devices (Reynolds Abstract). Spring is drawn to a 
device for creating and storing information that defines one or more network devices 
(Spring Abstract). Neither addresses all of the elements of the Applicants intelligent 
device upgrade engine. 

The Examiner uses Reynolds for the functionality disclosure and looks to 
Spring to provide the implementation in a computer program product. However, as 
seen above, Reynolds does not teach all elements of the functionality of this claim. 
Claim 18 contains the term "...monitoring program code for generating 
asynchronous with respect to said control program code, at least one event 
indication in response to a change of at least one predetermined attribute of said 
embedded device and forwarding said at least one event indication to said control 
program code..." As discussed above, Reynolds does not teach the monitoring of 
an attribute in the embedded device. Spring does not teach this either (it has no 
teachings on embedded devices), and the rejections under 35 U.S.C. § 103(a) must 
be withdrawn. 



Claim Rejections - 35 U.S.C. § 103(a) - Reynolds/Ording 

Claims 20-37 stand rejected by the Examiner under 35 U.S.C. § 103(a) as 
unpatentable over Reynolds in view of Ording. Applicants respectfully traverse this 
rejection. 

Reynolds is drawn to a common command interface to provide an 
interface abstraction for network devices (Reynolds Abstract). Ording describes the 
drawing of a progress bar on a screen (Ording Abstract). Neither addresses all of 
the elements of the Applicants claims. 
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Claims 20 and 33 are independent, and each contains elements missing 
from the combination of Reynolds and Ording. Each of claims 20 and 33 contain the 
element "...asynchronously, with respect to replacing said code image, monitoring 
progress of replacing said code image in said embedded device..." (claim 33, there 
is similar language in claim 20). 

Ording does not monitor the embedded device; there is no indication that 
Ording does any more than monitor itself. See [0024]: "Each time a predetermined 
event occurs, e.g. the computer's internal clock is updated, the index is incremented 
by the thread to point to the next image in the sequence." This is the only indication 
in Ording of the monitoring of any physical attribute, and the attribute comes from 
the computer itself, not from an embedded device as required by claims 20 and 33. 

Reynolds suffers from a similar deficiency. Reynolds does not monitor the 
embedded device either. In the discussion above, it is clear that during Reynolds's 
download to the boards, there is no monitoring at all, and certainly no monitoring of 
progress. The Examiner tries to use paragraphs [0119] and [0127] where the NMS 
servers accesses device statistics within a network device [01 19]. However, this has 
nothing to do with the SMS downloading an upgrade to a board. There is no 
correlation in Reynolds between the SMS and the NMS, nor is there any correlation 
between the board and the network devices. Each are different, unrelated elements. 

Since this element is not found in either Reynolds or in Ording, the 
rejection under 35 U.S.C. § 103(a) is not proper, and Applicants request that the 
Examiner remove this rejection from claims 20 and 33. 

Claims 21-32 depend upon independent claim 20 and claims 34-37 
depend upon independent claim 33, and all are distinct for the reasons described 
above. 

For these reasons, withdrawal of the rejection of claims 20-37 is also 
requested. 



U.S. Pat. Ser. No. 10/016,597 
July 6, 2006 
Page 15 of 15 



Conclusion 



The pending claims define subject matter that is distinct from both 
Reynolds, Spring, and Ording and Mayo. Claims 1-37 are pending and in condition for 
allowance. Applicants respectfully request prompt issuance of this application. 

The commissioner is authorized to charge deposit account 503650 for any 
fees associated herein. 
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